Description:

After #3213 got merged, the change with largest impact in #3193 was done in such a different way that a new PR was needed

The idea in 3193 was to not always ask for Transport Ship from buildableUnits. In such a way that very little extra data was send to the worker. This had the biggest impact on performance (the idea was months older btw, see #2295). Now, we do it the other way around, by telling buildableUnits all unit types we want. Or we want them all (undefined). The downside is more data is send in the worker message. The upside is we have more options and can add more in this PR.

This PR implements some of the leftovers in 3193 on top of 3213 and adds more.

• GameRunner: option to ask for no buildable units (null) in playerActions.

• Game / PlayerImpl: Typesafety and some added perf: new type PlayerBuildableUnitType so callers of buidableUnits can never ask for the wrong type like e.g. UnitType.Train because it doesn't return data for that type. This type is now used in aother applicable places too for the same reason.

• GameRunner: Fixes wrong assumption in Add units filter on playeractions for performance #3213: that only if units was undefined, we have to know canAttack. ClientGameRunner wants to know both, in case of a click on non-bordering land, to decide if it should auto-boat using a Transport Ship. So units is not undefined (we only ask for Transport Ship now which has a positive effect on performance for each click/tap) but we need canAttack still.
  Solved by removing the unit === undefined check before canAttack in playerActions. playerActions now has 3 modes: get all actions and all buildings (units undefined), get all actions and no buildings (units null), or get all actions and specific building (units contains Unit Types).

• GameRunner: But with above solved, there was still no option to only get buildable units. While StructureIconsLayer, NukeTrajectoryPreviewLayer, BuildMenu and UnitsDisplay need only that. To not make playerActions more convoluted with more params or so, i've added a new function playerBuildables to only get buildable units. playerBuildables has 2 modes: get all buildings (units undefined) or get specific buildings (units contains Unit Types).

• Have all callers of GameView .actions or .buildables, ultimately GameRunner playerActions and playerBuildables, ask for their type of units. Not only StructureIconsLayer and NukeTrajectoryPreviewLayer but also ClientGameRunner, BuildMenu, UnitsDisplay and PlayerPanel. Only MainRadialMenu needs all player buildable unit types including Transport Ship, so it can stay undefined there.

• PlayerImpl: validStructureSpawnTiles did a filter on unit types to get isTerroritoryBound units, on every call again. It read this from unit info in DefaultConfig so while that's good for maintainability, other code already uses hardcoded StructureTypes and isisStructureType from Game.ts. Which has the same purpose and thus contains the same unit types. StructureTypes and isisStructureType do need manual maintainance outside of DefaultConfig. And are more bug prone/less type safe. Still, using them gives more speed compared to putting it in some get function in GameImpl for example (tested with buildableUnits and MIRVPerf.ts. So went with StructureTypes in validStructureSpawnTiles.

• PlayerExecution: now validStructureSpawnTiles no longer needs isTerritoryBound (see the point above), PlayerExecution is the last place where it was used. Replaced it for isStructureType here too (since it has the same meaning and outcome).

• Game.ts and DefaultConfig unitInfo: removed isTerritoryBound as it was only used in validStructureSpawnTiles and PlayerExecution and has been replaced in both (see the two points above).

• PlayerImpl: Early return for non-upgradable unit types in findUnitToUpgrade. If it is upgradable, it will again check in canUpgradeUnit if the unit type is upgradable alas. Since canUpgradeUnit is also used by other code, this double check cannot be removed in a simple way. Still the early return makes the code faster as there are a number of units that can't be upgraded so we can skip all that happens in findUnitToUpgrade.

• PlayerImpl: buildableUnits would do Object.values(UnitTypes) on every call. Now only get player buildable units, exclude MIRVWarhead, TradeShip, Train, SamMissile and Shell. Since a player doesn't build those by themselves, they are only build by Executions which use canBuild directly instead of buildableUnits. Added PlayerBuildableTypes to Game.ts in the same fashion as existing StructureTypes and isStructureType.

• PlayerImpl: buildableUnits would check twice for tile!==null to decide to call findUnitToUpgrade and canBuild. Now once.

• PlayerImpl: buildableUnits would call canBuild which checks Cost, but then it fetches the Cost itself too. Now just do this once with canBuild accepting it as optional param. This does not affect other code that calls canBuild.

• StructureIconsLayer: In order to make type safety work in StructureIconsLayer for GhostUnit.buildableUnit.type too, changed type of interface BuildableUnit to PlayerBuildableType. Which is only more accurate. Same for uiState.ghostStructure and with that, renderUnitItem in UnitDisplay and setGhostStructure in InputHandler. All Structures are of PlayerBuildableType (there are even some in PlayerBuildableType that aren't Structures, but it is much more confined than UnitType).

• RadialMenuElements: replace non-central ATTACK_UNIT_TYPES in RadialMenuElements with centralized BuildableAttackTypes too. Use PlayerBuildableUnitType for more type safety (can't by mistake add UnitType.Train to its build menu). Make use of StructureTypes and BuildableAttackTypes instead of adding items hardcoded line by line in getAllEnabledUnits.

Some related (perf) changes:

• NationStructureBehavior: removed canUpgradeUnit check from maybeUpgradeStructure. Since it already checked this right before in findBestStructureToUpgrade, so only upgradable units are returned. Furthermore, UpgradeStructureExecution is called right after which also again checks canUpgradeUnit. So we're going from 3 times to 2 times canUpgradeUnit, small perf win on its own.

• NationStructureBehavior: instead of hardcoded ruling out Defense Post for upgrade check in maybeSpawnStructure, check dynamically if type is upgradable. That way if defense posts ever do become upgradable, we don't run into a bug right away.

• NationsStructureBehavior: in getTotalStructureDensity, we can pass an array of types as argument so we only have to get an array length once. It needs to ignore levels so we can't make use of other pre-defined functions in PlayerImpl (which were created to avoid array length calls), but at least this saves a few.

• GameImpl/GameView nearbyUnits: it accepted "UnitType | UnitType[]" for tiles, but called UnitGrid nearbyUnits which mandates "UnitType | readonly UnitType[]". Made the requirement the same for GameImpl/GameView nearbyUnits. This way, we don't have make a shallow copy of the StructureTypes array everytime we want to send it as an argument, from validStructureSpawnTiles and Util.ts. Other callers aren't affected.

(#3235) - ClientGameRunner: removed two redundant myPlayer===null checks since that was already done right above.

(#3235) - BuildMenu: Make playerBuildables have default value of null (null was already set as one of the possible values). Now we can remove the "?? []" check in canBuildOrUpgrade, since we already checked if playerBuildables is null when we get there, and even skip the assignment to const buildableUnits and loop over playerActions.buildableUnits directly.

(#3235) - RadialMenuElements: don't call canBuildOrUpgrade 3x in CreateMenuElements for the .map on flattenedBuildTable, instead do it once and re-use outcome.

(#3234) - Game.ts and DefaultConfig unitInfo: removed canBuildTrainStation and expirimental properties, as they already weren't used anywhere anymore.

(#3234) - PlayerActionHandler: remove unused getPlayerActions, the only potential caller MainRadialMenu already just calls myPlayer.actions via GameView directly.

(#3234) - StructureIconsLayer: remove already unused PlayerActions

(#3233) - Worker.worker: correct some existing error messages

(#3233) - BuildMenu: Fix some comments.

• And more

Please complete the following:

• I have added screenshots for all UI updates
• I process any text displayed to the user through translateText() and I've added it to the en.json file
• I have added relevant tests to the test directory
• I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced

Please put your Discord username so you can be contacted if a bug or regression is found:

tryout33